Skip to content

Conversation

@ymao1
Copy link
Contributor

@ymao1 ymao1 commented May 19, 2025

Towards #216313

Note

This PR will be merged into a feature branch

Summary

Adds internal APIs for listing and disabling scheduled reports. For this initial iteration, we are not adding an enable API.

This adds a Manage Scheduled Reports feature privilege that, if the user has it, allows them to view and disable the scheduled reports of any user in the current space.

To Verify

  1. Create a user (user1) with the ability to generate reports but not manage reports. Use the schedule API to schedule some reports as this user.
  2. Create another user (user2) with the ability to manage reports. Use the schedule API to schedule some reports as this user.
  3. As user1, use the Dev Console to list scheduled reports. You should only see those created by user1. user1 should also be able to disable their own reports.
  4. As user2, use the Dev Console to list scheduled reports. You should see reports from both user1 and user2. user2 should be able to disable a report created by user1.

ersin-erdal and others added 30 commits April 9, 2025 18:38
…:ersin-erdal/kibana into 216308-support-rrule-for-task-scheduling
… src/core/server/integration_tests/ci_checks'
…:ersin-erdal/kibana into 216308-support-rrule-for-task-scheduling
…:ersin-erdal/kibana into 216308-support-rrule-for-task-scheduling
… src/core/server/integration_tests/ci_checks'
…:ersin-erdal/kibana into 216308-support-rrule-for-task-scheduling
@ymao1 ymao1 self-assigned this May 30, 2025
@ymao1 ymao1 marked this pull request as ready for review May 31, 2025 14:42
@ymao1 ymao1 requested review from a team as code owners May 31, 2025 14:42
@SiddharthMantri SiddharthMantri self-requested a review June 4, 2025 16:24
Copy link
Contributor

@SiddharthMantri SiddharthMantri left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One nit regarding the authz config for the new route.

security: {
authz: {
enabled: false,
reason: 'This route is opted out from authorization',
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: Can this be expanded to better explain the reasoning for opting out?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Updated in 6030bf0

next_run: string | undefined;
notification: RawScheduledReport['notification'];
schedule: RruleSchedule;
title: RawScheduledReport['title'];
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This title is extracted from the jobParams, right?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, it currently is but we could also make it an explicit field set in the schedule API if that is preferable.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh no worries, I receive the title from the sharing data before creating the jobParams string so no need to specify it separately 🙂

Copy link
Member

@umbopepato umbopepato left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tested locally, works as expected, LGTM! 🚀
(Just dropped a few comments)

image

@pmuellr
Copy link
Member

pmuellr commented Jun 10, 2025

I tried out Verify steps with user1 and user2 and everything worked as expected. However, when I use a job id from user2 while logged in with user1 and do a bulk disable, I get the following:

{
  "scheduled_report_ids": [],
  "errors": [
    {
      "message": "Insufficient privileges to disable scheduled report \"c348b993-d106-482f-b538-3c9aee190a9f\".",
      "status": 403,
      "id": "c348b993-d106-482f-b538-3c9aee190a9f"
    }
  ],
  "total": 1
}

I'm wondering if we should return a 404 instead?

If we go that route, perhaps we can log the message we're currently generating as a WARN, since it's obviously useful info ...

@ymao1
Copy link
Contributor Author

ymao1 commented Jun 10, 2025

I'm wondering if we should return a 404 instead?

Updated in 6030bf0

Copy link
Member

@pmuellr pmuellr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, left some comments


export function scheduledQueryFactory(reportingCore: ReportingCore): ScheduledQueryFactory {
return {
async list(req, res, user, page = 1, size = DEFAULT_SCHEDULED_REPORT_LIST_SIZE) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Feels like we should put each route in a separate file, but perhaps we can plan on doing that when we add the next set of APIs (enable?)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds good. I was following what already existed for the jobs APIs but I guess we can start doing things the way we're used to in response ops now :)

});
} else {
// check if user is allowed to update this scheduled report
if (so.attributes.createdBy !== username && !canManageReporting) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if username is false, presumably we'd always go through this if block, maybe we could exit early instead?

// check if user is allowed to update this scheduled report
if (so.attributes.createdBy !== username && !canManageReporting) {
bulkErrors.push({
message: `Insufficient privileges to disable scheduled report "${so.id}".`,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the intention with a 404 is to not leak the existance of resources the client doesn't have access to. So the message should probably be "not found". Having the logged warn is good though, since it's ok to "leak" that info in the logs.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it considered a leak though? If we try to access a saved object that doesn't exist, we get a Saved object not found error that returns ${type}/${id} in the message. This only returns the ID that we're trying to disable, not any additional information about it.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think I understand what you're saying...I'll update the message to be a generic not found.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Updated in fbac095

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ya, I think my general experience with things is when you don't have access (haven't logged in), results tend to look like "I can't find that" - but not sure if we have guidelines about things like that ...

page,
perPage: size,
...(!canManageReporting
? { filter: `scheduled_report.attributes.createdBy: "${username}"` }
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

username can be false, at least type-wise, so in such cases (API keys?), this would search for reports by false.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good catch! We actually prevent scheduling reports if security is disabled and api keys are not available because we need that API key for scheduled reports. I probably carried over that typing from the normal reports so I'll fix the typing.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed the types, added a double check that username is specified and added a functional test to ensure we're getting an error when scheduling reports with security disabled: 1f6abbb

@elasticmachine
Copy link
Contributor

💚 Build Succeeded

Metrics [docs]

Public APIs missing comments

Total count of every public API that lacks a comment. Target amount is 0. Run node scripts/build_api_docs --plugin [yourplugin] --stats comments for more detailed information.

id before after diff
@kbn/reporting-common 94 97 +3

Async chunks

Total size of all lazy-loaded chunks that will be downloaded as the user navigates the app

id before after diff
fleet 1.8MB 1.8MB +78.0B

Page load bundle

Size of the bundles that are downloaded on every page load. Target size is below 100kb

id before after diff
reporting 50.7KB 50.8KB +78.0B
Unknown metric groups

API count

id before after diff
@kbn/reporting-common 104 107 +3

ESLint disabled line counts

id before after diff
@kbn/test-suites-xpack 666 669 +3

References to deprecated APIs

id before after diff
reporting 7 9 +2

Total ESLint disabled count

id before after diff
@kbn/test-suites-xpack 687 690 +3

History

cc @ymao1

@ymao1 ymao1 merged commit c6e35e7 into elastic:scheduled-reports Jun 10, 2025
10 checks passed
@ymao1 ymao1 deleted the scheduled-reports-find branch June 17, 2025 11:50
ymao1 added a commit that referenced this pull request Jun 19, 2025
Resolves #216313

## Summary

This is a feature branch that contains the following commits. Each
individual linked PR contains a summary and verification instructions.

* Schedule API - #219771
* Scheduled report task runner -
#219770
* List and disable API - #220922
* Audit logging - #221846
* Send scheduled report emails -
#220539
* Commit to check license -
f5f9d9d
* Update to list API response format -
#224262

---------

Co-authored-by: Ersin Erdal <[email protected]>
Co-authored-by: kibanamachine <[email protected]>
Co-authored-by: Ersin Erdal <[email protected]>
Co-authored-by: Elastic Machine <[email protected]>
Co-authored-by: Alexi Doak <[email protected]>
ymao1 added a commit to ymao1/kibana that referenced this pull request Jun 20, 2025
Resolves elastic#216313

## Summary

This is a feature branch that contains the following commits. Each
individual linked PR contains a summary and verification instructions.

* Schedule API - elastic#219771
* Scheduled report task runner -
elastic#219770
* List and disable API - elastic#220922
* Audit logging - elastic#221846
* Send scheduled report emails -
elastic#220539
* Commit to check license -
elastic@f5f9d9d
* Update to list API response format -
elastic#224262

---------

Co-authored-by: Ersin Erdal <[email protected]>
Co-authored-by: kibanamachine <[email protected]>
Co-authored-by: Ersin Erdal <[email protected]>
Co-authored-by: Elastic Machine <[email protected]>
Co-authored-by: Alexi Doak <[email protected]>
(cherry picked from commit a409627)

# Conflicts:
#	src/platform/packages/private/kbn-reporting/common/routes.ts
#	x-pack/platform/plugins/private/canvas/server/feature.test.ts
#	x-pack/platform/plugins/private/reporting/server/core.ts
#	x-pack/platform/plugins/private/reporting/server/features.ts
#	x-pack/platform/plugins/shared/features/server/__snapshots__/oss_features.test.ts.snap
#	x-pack/platform/test/api_integration/apis/features/features/features.ts
#	x-pack/test_serverless/api_integration/test_suites/chat/platform_security/authorization.ts
#	x-pack/test_serverless/api_integration/test_suites/observability/platform_security/authorization.ts
#	x-pack/test_serverless/api_integration/test_suites/search/platform_security/authorization.ts
#	x-pack/test_serverless/api_integration/test_suites/security/platform_security/authorization.ts
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants